Technical

 

The content model component is a complex entity, which comprises of the following sub-components: content types, property bundles, properties and relations. The plugins in the system, which build this component, start with com.tetracom.atlas.content.model . The picture below shows the links between the sub-components:

 

 

A content type is a set of one or more property bundles. A property bundle is a container for one or more properties. A relation represents the bond between two content types.

Important classes:

content model

ACMEntity – parent class for all content model entities described below.

content type

ContentTypeCommon – stores information about the property bundles, which the content type includes.

property bundle

CTPropertyBundleCommon – contains the properties of the bundle.

property

There are three property groups in the system – common, lookup and file. These groups include seven property types – short text, long text, date, number, lookup, single file and multiple file. The important classes, which represent these types, all derive from the ACTProperty abstract class. It stores the common property data – the parent bundle and whether the property is multilingual.

Common - includes short text, long text, date and number properties.

CTPropertyCommon – the class uses an enumeration that defines which of the four common propertiesare represented by the instance.

Lookup

CTPropertyLookup – specifies the lookup which is used in the property.

File – includes single and multiple files

CTPropertyFile – uses an enumeration to define whether the property is a single or multiple file.

relation

There are three types of relations. They all extend the ACTRelation abstract class. It includes the common settings for all relation types – the content type at the first end and the relation's cardinality. The latter signifies the number of content items at each end of the relation. Currently, there are three types of relation cardinality : one-to-one, one-to-many and many-to-many. This division is done based on the content items which represent this content type relation.

Example: We have two content types (Author and Publication) and a relation between them. The relation cardinality should be:

1.One-to-one if we want a publication to have exactly one author and each author has exactly one publication.

2.One-to-many if we want an author to have one or more publications. Howerver, each publication has only one author in this case.

3.Many-to-many if we want a publication to have one or more authors. Moreover, each author may have one or more publications.

Common relations- these are basic relations between two different content types.

CTRelationCommon – provides information about the second content type of the relation.

Self relations – the same as the common relations, but the same content type is at both ends of the relation.

CTRelationSelf – does not provide information about the other end of the relation as the content type is the same as the first.

Unspecific relations – these have one content type at the first end of the relation and one or more content types at the other end.

CTRelationUnspecific – provides a set of content types, which form the second end of the relation.

 

The picture below depicts the classes described and their inheritance.

 

 

 

 

Important services:

 

IContentTypeFacadeProviderService – provides access to the content types in the system.

ICTPropertyBundleFacadeProviderService – provides access to the property bundles in the system.

ICTRelationFacadeProviderService - provides access to the content type relations in the system.

ICTPropertyFacadeProviderService – provides access to the content type properties in the system.

IContentModelFacadeService – this service unites the four mentioned above and basically allows the loading any content model entity.